fix: bound stale running turn recovery - #83

Thanks for the thorough writeup and the clean minimal fix — the approach is correct and has been carried forward.

I've rebased your work onto current main (main moved substantially since 8/27: the cancel drain gate, v4/command stop, and steer-report rework landed in the same loop) as #85, with three adaptations:

1. probePromptLock now matches the lock-busy error by code 1308 first (message text kept as fallback) — same rationale as the send-retry loop; message drift between backend releases would otherwise kill a live turn.
2. Dropped the deadline else if (turn.cancelled) branch — main's in-loop cancel check already covers it; keeping it would misreport a user cancel as max_turn_requests.
3. Regression tests' microtask pump raised 20 → 80 (main's prompt() gained more async preamble).

On your open policy question: no hard cap on lock-held deferral. Backend-owned long work is legitimate and user cancel remains the escape hatch; a follow-up will surface deferral to the client as a visible session/update note instead of a cap.

Closing this in favor of #85 — your commit is preserved there (rebased, credited in the commit chain).

Thanks for carrying this forward and preserving the attribution. The adaptations make sense, especially matching code 1308 and avoiding the redundant cancelled branch.

I agree with keeping lock-held deferral uncapped while user cancellation remains available. Surfacing the deferral through a visible session/update note sounds like the right follow-up.

Glad to see this merged in #85. Thanks again!